--

Sysstat

Overview

Sysstat is a collection of Linux performance monitoring tools (including sar, iostat, mpstat, pidstat, and others) used to observe CPU, memory, disk I/O, and network activity. It supports both real-time inspection and historical reporting by collecting system activity samples on a schedule.

History

• As Linux deployments scaled and performance troubleshooting became routine, sysstat tools emerged to provide consistent, low-overhead performance metrics.
• The sar subsystem popularized scheduled sampling and historical analysis on commodity servers without requiring a full monitoring stack.

Adoption

Sysstat is commonly used in:

• VPS and bare-metal Linux servers for baseline performance diagnostics
• Incident response and troubleshooting (spikes, saturation, latency)
• Capacity planning and trend analysis with historical sar data
• Environments where lightweight local tooling is preferred over centralized telemetry

Maintainer

Maintained by the sysstat project/community and packaged by Linux distributions.

Best when to use

• You need reliable, low-overhead performance metrics on a Linux host
• You want both real-time tools and historical views without external dependencies
• You need quick root-cause signals for CPU, I/O wait, disk saturation, or process hotspots

Not suitable when

• You need cross-host correlation and long-term retention at scale (use a metrics platform)
• Your environment is not Linux (sysstat is Linux-focused)
• You need deep application-level tracing rather than host-level counters

Compatibility notes

• Sysstat is Linux-specific and relies on kernel statistics interfaces.

• Data collection is usually enabled via:

  • cron on some systems, or
  • systemd timers and services on others.

• Paths and service names vary by distribution (for example, sysstat service on Debian/Ubuntu, or timer-based collection elsewhere).

Scope

This page focuses on operationally safe usage: verifying collection, reading sar history, and diagnosing common CPU, memory, disk, and network issues.

What’s included

Common sysstat commands:

Tool	Focus	Typical use
-	--
sar	Historical system activity	“What happened at 03:00?”
iostat	Disk and device I/O	Identify disk saturation, await, util
mpstat	CPU per-core stats	Spot single-core saturation
pidstat	Per-process stats	Find which process is consuming CPU/I/O
sadf	Export sar data	Convert to CSV/JSON-like formats
tapestat	Tape devices	Rare in VPS contexts

Installation

Debian/Ubuntu

sudo apt update
sudo apt install sysstat

Fedora/RHEL family

sudo dnf install sysstat

Arch

sudo pacman -S sysstat

Verify installation (read-only)

sar -V
iostat -V 2>/dev/null || true
mpstat -V 2>/dev/null || true
pidstat -V 2>/dev/null || true

Enable and verify data collection

Sysstat can run without historical collection (real-time tools still work). For sar history, scheduled collection must be enabled.

Check whether sar data exists (read-only)

Common locations:

• /var/log/sysstat/
• /var/log/sa/

Check:

ls -la /var/log/sysstat 2>/dev/null || true
ls -la /var/log/sa 2>/dev/null || true

If you see files like sa15 or sar15, collection is active.

Debian/Ubuntu: enable sysstat collection

On many Debian/Ubuntu systems, collection is controlled by a config flag.

Check:

sudo grep -E 'ENABLED=' /etc/default/sysstat 2>/dev/null || true

If disabled, set:

ENABLED="true"

Then enable/start the service:

sudo systemctl enable --now sysstat

RHEL/Fedora: verify timers/services

Check timers/services:

systemctl status sysstat 2>/dev/null || true
systemctl list-timers | grep -i sysstat || true

Scheduling differences

Some distros schedule collection every 10 minutes by default; others differ. Confirm by checking timestamps on sa* files and reviewing sysstat configuration.

Common commands and examples

sar (historical view)

View today’s CPU usage

sar -u

View CPU usage for a specific time window

sar -u -s 09:00:00 -e 11:00:00

Memory usage

sar -r

Swap activity

sar -W

Load average and run queue

sar -q

Network statistics

sar -n DEV

Read a specific day’s data file

If your data is in /var/log/sa/sa15:

sar -u -f /var/log/sa/sa15

Time-correlated troubleshooting

Use sar -u, sar -r, and sar -n DEV for the same time interval to correlate CPU saturation, memory pressure, and network bursts.

iostat (disk I/O)

Extended stats with 1-second sampling (5 samples)

iostat -xz 1 5

Key fields:

Field	Meaning	Investigation hint
-	--
%util	Device busy time	Sustained ~100% suggests saturation
await	Average request latency	High await with high util suggests bottleneck
r/s, w/s	Reads/writes per second	Shows workload shape
rkB/s, wkB/s	Throughput	Useful for bandwidth constraints

mpstat (CPU per-core)

mpstat -P ALL 1 5

Use when:

• Overall CPU looks fine but latency is high
• Single-threaded workloads saturate one core

pidstat (per-process)

CPU per process

pidstat -u 1 5

I/O per process

pidstat -d 1 5

Memory faults and usage

pidstat -r 1 5

Practical use cases

Diagnose “server is slow” complaints

1. Check CPU and run queue:

sar -u -q

2. Check memory pressure:

sar -r -W

3. Check disk saturation:

iostat -xz 1 5

4. Identify top consumers:

pidstat -u -d 1 5

Identify swap thrashing

Swap in/out spikes correlate with severe slowdown.

sar -W -s 09:00:00 -e 10:00:00

If swap activity is sustained, investigate memory overcommit, too many workers, or oversized DB/cache allocations.

Troubleshooting

sar shows “Cannot open /var/log/sa/saXX”

Causes:

• sysstat collection not enabled
• data directory path differs
• permissions issue

Checks:

ls -la /var/log/sa 2>/dev/null || true
ls -la /var/log/sysstat 2>/dev/null || true
systemctl status sysstat 2>/dev/null || true

Data exists but timestamps are wrong

Causes:

• system time changed (NTP corrections or manual changes)
• VM restored from snapshot with time drift

Fix:

• Ensure NTP is enabled and stable.
• Treat historical sar data around the time change with caution.

High %iowait but low CPU usage

Likely a disk bottleneck. Confirm with:

iostat -xz 1 5

If %util is high and await is elevated, reduce I/O load, optimize queries, or move to faster storage.

Security notes

Sysstat tools are read-only and generally safe. The main security considerations are:

• Historical logs may reveal workload patterns (treat as operational data)
• Restrict access to /var/log/sa if your environment considers performance data sensitive

Least privilege

Allow access to sysstat data only to operators who need it for troubleshooting and capacity planning.

Quick reference

Goal	Command
	--
Check versions	sar -V
CPU now (5 seconds)	sar -u 1 5
CPU history	sar -u
Memory history	sar -r
Swap history	sar -W
Load/run queue	sar -q
Network per interface	sar -n DEV
Disk I/O live	iostat -xz 1 5
Per-core CPU	mpstat -P ALL 1 5
Per-process CPU	pidstat -u 1 5
Per-process I/O	pidstat -d 1 5
List sar files	ls -la /var/log/sa